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Foreword 


The G-TOR data communications protocol is an 
innovation of the technical staff of Kantronics 
Co., Inc. It was introduced as an inexpensive 
means of improving digital communications 

in the HF radio bands. A hybrid ARQ scheme, 
used in combination with an invertible, half- 
rate Golay forward error correcting code, is the 
single-most essential element in the protocol. 


The purpose of this document is to present 

a detailed description of the G-TOR protocol. 
It is assumed that the reader is familiar with 
ARQ systems such as AMTOR, Pactor, and 
Packet; terms such as MASTER, SLAVE, ISS, 
IRS as they pertain to protocols; and binary, 
HEX and C-language number notations. Oper- 
ation, performance objectives, and performance 
results of systems using this protocol are not 
discussed; these aspects of G-TOR have been 
covered widely in trade publications. 


The description is organized in sections as 
follows: a general overview, including term 
definitions and initialization of parameters; 
timing; definition and usage of data, control, 
BK, and connect and disconnect frames; data 
formats; speed change procedures; the Huff- 
man table; and Golay coding and data inter- 
leaving. Appendices containing flow charts, 
a Huffman decoding tree, and a C language 
routine for Golay encoding/decoding follow 
the protocol description. 


General 


The system which originally transmits a 
G-TOR connect request is called the Master, 


and the system which responds to the trans- 
mitted connect request is called the Slave. 

The system currently sending data blocks is 
called the Information Sending Station (ISS), 
and the system receiving these data blocks is 
called the Information Receiving Station (IRS). 
During a connection, tlhe Master is always the 
Master and the Slave is always a slave, but 
either system may be the ISS while the other 
is the IRS. Immediately after a connection, the 
Master is the ISS while the Slave is the IRS. 
The IRS will send a Control Signal #1 (CS1) 
immediately after connection or turnaround to 
indicate it is ready for data; it sets an internal 
flag (Send_CS_flag) to CS1. The IRS also sets 
its internal error count to 0, its blocks_received 
count to 0, and its Last Block number to 0. 
When the ISS receives the CS1, it sets an 
internal flag (Expecting_CS_flag) to CS2 and 
Block_number to 1. 


The Master and the Slave both have an 
internal flag (Golay_flag) which is comple- 
mented every 2.4 second cycle. During the 
connect process, this flag is set to be the same 
in both systems. Whenever the ISS receives 

a proper Acknowledgment (the CS1 the first 
time around), it forms a new frame of data 
(Real_Data). This new data frame is also fed 
through the Golay encoder to form a frame 

of parity bits (Golay_Data). The ISS sets an 
internal error count to 0. Depending on the 
state of the Golay_flag in the ISS, the ISS will 
choose the Real_Data frame or the Golay_Data 
frame to transmit. The Golay_flag in the ISS is 
then complemented for the next cycle. Which- 
ever frame is chosen, that frame is then inter- 
leaved and transmitted. 
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Figure 1 
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The IRS is expecting to receive a frame during 
a certain time period in the 2.4 second cycle. 
When it has received the frame, the IRS then 
increments its Blocks_received count and de- 
interleaves the block. If the ISS Golay_flag is 
set, a copy of the block is saved as Golay_Data; 
the block is then fed through the Golay encoder 
to generate the original data. If the ISS 
Golay_flag is clear, a copy of the block is saved 
as Real_Data. The Golay_flag is then comple- 
mented. If the CRC of the block is correct, the 
IRS has received the data correctly. If the 

CRC is not correct, the IRS checks to see if 
the Blocks_received counter is greater than 1, 
indicating it has received a copy of both the 
Real_Data and the Golay_Data. If the IRS has 
a copy of both, it will try to regenerate the orig- 
inal data using Golay error correction. If the 
CRC is still incorrect, the IRS error count is 
incremented. If the error count is greater 

than a set maximum number of errors, the 
IRS will go back into a standby mode; other- 
wise, to indicate failure, the IRS will re-send 
the same Control Signal it sent in the last 
cycle. If the CRC of the received block or the 
error corrected block is correct, the IRS clears 
its Blocks received count and compares the 
Block_number in the received frame with 

the Last_Block number it correctly received. 

If they are the same, then the received data 
frame is the same, indicating most likely 

that the ISS has not correctly received the 

last Control Signal sent by the IRS; the IRS 
then re-sends the last CS. If the Block_number 
is one greater than the Last_Block number 
received, then this block is the next data 
expected; the IRS now sets its Last_Block 
number to the Block number received and 
prints the data received; the IRS error count 
is set to 0; the Send_CS_flag is complemented 
and the appropriate Control Signal is trans- 
mitted. If the Block number is otherwise, then 
some protocol error has occurred, and data 

has been lost. 


The ISS is expecting to receive an acknowledg- 
ment during a certain time period in the 2.4 
second cycle. If the ISS receives a CS2 when 

it was expecting a CS2, or it receives a CS1 
when it was expecting a CS1, the ISS considers 
the sent data to be properly acknowledged. 
The Expecting_CS_flag is complemented, the 


Block_number is incremented, and the ISS 
fetches new data to be transmitted. Otherwise, 
the data has not been acknowledged, or the 
ISS has not received the acknowledgment. 
The ISS then increments its error count, and 
if the error count is less than some set maxi- 
mum, the ISS will try to send the data again. 
Timing 

The basic G-TOR cycle is very similar to 
AMTOR and PACTOR. The ISS sends long 
data frames which are acknowledged by 

the IRS with shorter control signals (CS). 

The total cycle duration is 2.4 seconds. The 
data frames are 1.92 seconds long and the 
control signals are 0.16 seconds long. 0.32 
seconds remain in the cycle for radio switch- 
ing, wave propagation, and the necessary 
computing for both Master and Slave systems. 
The Master controls tlhe total cycle time. The 
Slave adjusts its receive window to follow the 
Master’s transmissions, but since the Slave’s 
transmissions are always fixed in relation to 
its receive window, the Slave’s transmissions 
follow the Master’s transmissions. The Master 
only corrects its receive window. Refer to 
Figure 1. 


Data Frame Structure 


The frame structure for a typical G-TOR data 
frame (before interleaving) is shown in Figure 
2. The data frame is 1.92 seconds in duration. 
Depending on channel conditions, data can be 
sent at 100,200, or 300 baud. Each data frame 
is composed of either 72 bytes (at 300 baud), 48 
bytes (at 200 baud), or 24 bytes (at 100 baud). 


Figure 2 
G-TOR Frame Structure Before Interleaving 
Status CRC 
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A single byte near the end of the frame is 
devoted to command and status functions. 
The status byte is interpreted as follows: 


° status bits 7 & 6: 
Command 
00 — data 
01 — change-over request 
10 — disconnect 
11 — connect 


« status bits 5 & 4: 
Unused 
00 — reserved 


- status bits 3 & 2: 
Compression 
00 — none 
01 — Huffman 
10 — Swapped Huffman 
ll-reserved 


e status bits I1&O: 
Block Number modulo 4 


The last 2 bytes of the frame contain the CRC. 
Like Packet and Pact-or, the CRC is computed 
using the same CCITT standard, starting at 
the first byte of a data, connect, or disconnect 
frame and starting at the third byte of the BK 
frame. However, the two bytes of the CRC are 
swapped before being put in the frame. 


Control Signal Structure 


The G-TOR Control Signals (CS) are 2 bytes 
(16 bits) long and are always sent at 100 baud. 
Each byte of the Control Signal is sent LSB 
first. Control Signals are used to acknowledge 
correct or incorrect receipt of frames from the 
information sending station. They are also 
used to request changes in transmission speed 
and to initiate a change-over in information 
flow direction. There are five different G-TOR 
Control Signals: 


Signal-Function Code Bit pattern in time 
CS1-Data ack/nack F11A 1000111101011000 
CS2-Data ack/nack 6B62 1101011001000110 
CS3-Change-over 


command 5E13 0111101011001000 
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CS4-Speed change 4D8C 1011001000111100 
CS5-Speed change 8957 1001000111101010 


The CS codes are composed of multiple cyclic 
shifts of a single 15-bit pseudo-random noise 
(PN) sequence (an extra ‘0’ bit is appended to 
the sequence for balance, so the total CS word 
length is 16). A pseudo-random noise sequence 
is used because PN sequences have powerful 
mathematical correlation and distance prop- 
erties which facilitate the identification of the 
appropriate CS code, even in the presence of 
noise and interference. Each CS has a mutual 
Hamming distance of 8. 


BK Frame Structure 


The change-over frame is shown in Figure 3. 
This frame is always transmitted at 100 baud 
and is never interleaved. It is essentially a 
combination of the CS3 Control Signal and 

a shortened data frame. Each byte of the BK 
frame is sent LSB first. 


Figure 3 
G-TOR Changeover Frame Structure 


1.92 sec 


cs3 Data Status CRC 
(2 bytes) (19 bytes) (1 byte)| (2 bytes) 


Formation of Connect and Disconnect 
Frames 


Connect and Disconnect frames are always 
sent at 100 baud (24 bytes). The first 10 bytes 
contain the call/address of the destination and 
the second 10 bytes contain the call/address 
of the source. These 20 bytes use 7 bit ASCII. 
If the call/addresses are less than 10 bytes 
long, the fill character OxOF should be used 

to extend the addresses to 10 bytes. 


The 21st byte is zero. Bytes 23 and 24 are 

the CRC. Byte 22 is the status byte and will be 
11000000 for a connect frame or 100000xx for a 
disconnect frame. Note that the Block Number 
for a connect frame is always 0. 


The MSB of the first 20 bytes are originally 
zero because of the use of 7 bit ASCII. Bytes 2, 


Figure 4 


47 54 4F 52 54 4F 43 41 4C 4C 4D 59 43 41 4C 4C OF OF OF OF 00 CO ?? ?? 


\/ \/ \/ Nf 


\/ \/ \/ 


becomes 


/\ /\ /\ /\ 
47 4D 4F 52 4D4F 43 1C 4C 4c DC 59 


5, 8, 11, 14, 17, and 20 should now have their 
MSB set to one; then the nibbles of these bytes 
should be swapped. For example, a connect 
frame to GTORTOCALL from MYCALL would 


form as shown in Figure 4. 


The reason for this strange format is that 
when the frame is broken up into 12 bit 
tribbles and sent to the interleaver, 


474 D4F 524 D4F 431 C4C 4CD C59 
431 C4C 4CF 80F OFF 800 COF 5E4 


the first 14 bits transmitted (the MSBs of the 
tribbles) will be alternating Os and 1s. Note 
that this pattern is not present when the Golay 
form of the frame is being sent. 


The Slave should also look for connect frames 
with mark and space inverted, and the Master 
should also look for inverted Control Signals. 
Once connected, each station should remember 
its received polarity. 


When the Slave decodes a connect frame 
addressed to it, the Slave would normally 
answer with a CS1 control signal. If the Slave 
is busy, it would answer with a CS2. If the 21st 
byte is not zero, or the 6 lower bits of the sta- 
tus byte are not zero, the Slave should answer 
with a CS5; this is for future expansion — the 
Master indicating it has added capabilities, 
the Slave indicating it does not yet support 
those capabilities. 


The Slave must be careful about ‘when’ it acks 
the Master. Like Amtor and Pactor, the Slave 
sets a fixed time after the Master’s transmis- 
sion for its own transmission. For maximum 
propagation, the Slave should set this time as 
short as possible. However, the time should be 
long enough so that it can not only decode and 
possibly correct a data frame before sending 
the ack as an IRS, but also long enough to form 
a data frame when an ack is received from the 
ISS. In other words, the Slave must be aware 
of the time needed for its own processing. 


/\ /\ eX 


AS ACO AC IS sO OF Be WOO: «COs b> EA 


The connect and disconnect frames are always 
sent at 100 baud. If the ISS wants to discon- 
nect but is transmitting at a higher baud rate, 
it should send an idle frame with a status byte 
100000xx; when the IRS sees this frame, it 
should send a CS5 to downspeed the ISS but 
should stay connected until the ISS sends a 
true disconnect frame. 


After the IRS acknowledges a disconnect 
frame, it should remember the time relation- 
ship between the disconnect frame and the 
IRSs ack. If the ISS did not copy the ack, it will 
keep sending disconnect frames until it times 
out. If the IRS copies a disconnect frame to it 
while in standby, it should re-send the last ack. 


Data Format in Frames 


The ISS can send data in three forms: straight 
ASCII, Huffman compressed, and swapped 
Huffman compressed. Swapped Huffman uses 
the same tables as Huffman compressed but 
swaps the upper case letters with the lower 
case. Since Huffman compressed favors lower 
case letters as in normal text, Swapped Huff- 
man favors upper case letters in text which 
may be predominately upper case. The ISS 
must decide in which form to send the data 

in order to provide the greatest throughput; 

if there is no advantage in sending Huffman 
codes, the ISS should send in straight ASCII. 
All normal data frames and connect and dis- 
connect frames are interleaved and, on alter- 
nate cycles, Golay encoded. 


If there is not enough data to send in a data 
frame, IDLE codes are used to fill the frame. 

If the frame is sending straight ASCII, 0x1E is 
used as the IDLE code. In order to send a 0x1E 
data byte, a Ox1C pass code must be sent fol- 
lowed by 0x7E; in order to send a 0x1C data 
character, a 0x1C pass code must be sent fol- 
lowed by 0x7C. Only the ASCII data charac- 
ters 0x1C and Ox1E need a pass code. The pass 
code should never be the last character in an 
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ASCII data frame; in other words, the combi- 
nations 0x1C 0x7E and 0x1C 0x7C should 
never be split between data frames. G-TOR 
Huffman compression uses a unique IDLE 
code; there is no pass code when sending a 
Huffman compressed frame. 


The IDLE code also indicates the end of data 
in a data frame: straight ASCII or Huffman 
compressed. The IRS should stop decoding the 
data frame when it encounters an IDLE code, 
and the ISS should never send data after an 
IDLE code in a data frame. This function is 
reserved for possible expansion. 


BK Frames 


If the IRS wants to send data to the ISS, it can 
seize the link and become the ISS by sending 
a BK frame. The BK frame is a special data 
frame which is always sent at 100 baud and is 
never interleaved nor Golay encoded. The first 
16 bits of the BK frame comprise the CS3 con- 
trol signal. The next 22 bytes are 19 bytes of 
data plus the status byte and 2 byte CRC 
formed over the data starting after the CS8. 
The Block Number in the status byte of the BK 
frame is always 0. Each byte is sent LSB first. 
If the ISS receives the BK frame correctly, it 
sends a CS1 and becomes the new IRS, expect- 
ing new data frames at the previous baud rate. 
If the ISS detects the CS3 but does not receive 
the data correctly, it sends a CS2 and becomes 
the new IRS, still expecting data at the previ- 
ous baud rate. If the original sender of the BK 
frame received a CS2, it will re-form a data 
frame using the old data that was used in the 
BK frame plus any additional data available, 
but again at the baud rate in use before the BK 
frame was sent. If the sender of the BK frame 
receives neither a CS1, CS2, or CS3, it will 
re-send the original BK frame. 


Since there is a possibility that the ISS 

does not receive the CS3 part of the BK frame 
and therefore will re-send a data frame or 

the Golay encoded form of the data frame, the 
ISS must ensure that any data frame or Golay 
encoded form of a data frame will not produce 
a waveform which would appear as a 100 baud 
CS1, CS2, or CS3 in the time slot where the 
IRS may be looking for an acknowledgment to 
its BK frame. The IRS should be sampling in 
the receive ack time slot at the previous baud 


D4 


rate to ensure that the ack received is truly a 
100 baud signal and not an artifact of the ISS 
data frame at a higher speed. 


The ISS can request a changeover by sending 
a data frame with bit 6 of the status byte (BK 
request bit) set to 1 (0100xxxx); the IRS would 
then send a BK frame. A BK frame can also be 
acknowledged with another BK frame, causing 
quick changeovers. The BK frame serves as 

a positive acknowledgment of the previously 
received data. 


Changing Speed 


Data frames can be sent at 100,200, or 300 
baud. CS4 and CS5 are the Control Signals 
that the IRS uses to change the sending speed 
of the ISS. Since the IRS can cause the ISS to 
change from any one speed to any other speed, 
the Control Signal used by the IRS depends 
on the states of the two systems. Refer to the 
Speed Transition Diagram in Figure 5. The 
algorithm used by the IRS to determine speed 
changes is not a part of this protocol. The algo- 
rithm used by the KAM, however, is shown in 
the flowcharts. A speed-up CS always acts as a 
positive acknowledgment of the previous data 
frame. A speed-down CS asks for the previous 
data to be re-sent at a slower speed. 


Slowdowns and BK Frames 


If the ISS receives a slowdown signal from 
the IRS, it has no way of knowing whether the 
data just sent was received correctly or not and 
therefore should re-send the data at the re- 
quested slower speed using the same block 
number. It is possible that the IRS could 
request a further slowdown in speed while 
the ISS is re-sending data. Any time the 

IRS receives valid data, it should keep a 

count of the characters in the frame. If the 
IRS slows the ISS down and the new data 
frame received has the same block count as 
the previous frame, the IRS knows the ISS is 
resending data and should throw away the 
appropriate number of characters. The ISS 
and IRS need to be careful with these charac- 
ter counts during double slowdowns (from 300 
to 200 and then from 200 to 100 baud). 


If the IRS tells the ISS to slow down after the 
ISS has sent a data frame with the BK request 
bit set, or if the ISS decides it wants to send a 


Speed transition diagram 
Fi gure5 
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BK request while re-sending data in response 
to a slowdown, the ISS should not set the BK 

request bit in the slower data frames until the 
data frame contains the last character sent in 
the original. 


The IRS cannot send a BK frame until it 
receives a valid data frame since the CS3 of 
the BK frame is an acknowledgment of valid 
data. If the IRS is receiving duplicated data 
due to a slowdown, it should not send a BK 
frame until all the duplicated data is received. 


RLEn Coding 


An RLEn code is a 19 bit code made up of a 
unique 14 bit Huffman code followed by 5 bits 
which represent a number n, O-31. RLEn codes 
are found only in Huffman compressed data 
frames and can never be the first code in a 
data frame. 


When an RLEn code is encountered in a data 
frame, the previous character decoded in the 
frame should be repeated an additional N 
times, where N is a number which depends on 
n and the number of bits used by the previous 
Huffman character according to the following 
table. 


length of previous character N 
2 bits n+10 
3 bits n+7 
4 bits n+o 
5-6 bits n+4 
7-9 bits n+3 
10-16 bits n+2 


An RLEn code may follow another RLEn code 
immediately, indicating that the previous code, 
which was just repeated, should be repeated 
an additional N times. 


Huffman codes are put into the data fields in 
the order shown in Appendix 11. For example, 


the first few bytes of “The quick brown fox” 
using Huffman compression would be formed 
as shown in Figure 6. 


And before interleaving or Golay encoding, 
the bytes are grouped into tribbles 


1A2 3BD 6FE A65.... 


Golay Coding and Interleaving 


Before a data frame is transmitted, the data 
is regrouped into 12 bit tribbles. For example, 
a 100 baud frame of “The quick brown fox” 
using no compression would be formed like: 


94. OO. WO. 42.0- “le ko 26.9" 265- 6B 
20. 62: AZ. 6B SI OE. 2.0" 6.6.6 
78 1E IE Ol 7E 064 


And then grouped into tribbles 


946: 865 207 Lio: “696 S68 
206 2/2 -6F7 76E 206° 66F 
781 E1E O17 E64. 


The data is interleaved by sending in time the 
MSB of each tribble, and then the next MSB, 
etc. The bit sequence of the above data would 
start: 


time-> 
0100000000000101 
LOOOLOGOLLO TT 162. 
(GT st Bs et BD es a Pt Wl 
1001010001001000 
8 more groups of 12 bits 


The ISS alternately sends frames of data and 
Golay encoded data. Golay codes are unique 
1%bit codes derived from 12 bits of data. The 
C program in Appendix 10 shows how to gen- 
erate the codes from the data and also how to 
regenerate the correct data from the 24 bits of 
data and Golay codes which have errors. The 
correction algorithm will correct up to 3 bits 
in error from the 24 bits of data and encoded 
data. The Golay codes are generated from the 


Figure 6 
T h e q i C k 
0001101 000100 011 10 1111010110 11111 1101 010011 0010101 
HOOT LONG? OOL0COT1- LOTTO OL 01? DITO10TO: CLLOOTOL Olaese ss 
23 BD 6F EA 65 
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tribbles of data before interleaving, so that 
“The quick brown fox” 


546 865 207 175 696 36B 206 272 
6F7 76E 206 66F 781 ELE 017 E64 


becomes 


083 092 57B 1A7 F88 C46 A85 AFI 
9AE 342 A85 291 114 BAF OB1 3F0. 


The tribbles are then interleaved as before, 
starting with the MSB of the first tribble. 


Note that the CRC of the original data is also 
Golay encoded; there is no CRC generated 
over the Golay encoded frame. 


Note also that the inverse Golay function is 
identical to the Golay function; in other words, 
x=g(g(x)). 


FEC Transmissions 


At this time there is no special G-TOR broad- 
casting mode. AMTOR mode B is used for call- 
ing CQ. A G-TOR unit in standby should be 
able to receive AMTOR mode B FEC signals. 


Monitoring G-TOR 


Third party monitoring of G-TOR connects 
can be very difficult due to the nature of the 
G-TOR protocol. Although a data frame is 


always 1.92 seconds long, it may have been 
sent at 100,200, or 300 baud. The frame 
received may be the Golay encoded form of a 
data frame. The BK frame is different in that 
it is not interleaved, and its CRC is calculated 
over shortened data. The frame received could 
also be inverted polarity; however, the inver- 
sion would stay the same during any particu- 
lar connection. Since the Golay error correction 
allows the IRS to copy data without ever get- 
ting a proper CRC in one frame, a monitor pro- 
gram should also go back 2.4 seconds to form 
a correct frame if it is to be thorough. Again, 
because of the nature of the G-TOR signal, 
Carrier Detect or a PLL on bit transitions 
cannot be used reliably, but a brute force algo- 
rithm can be used. It would sample the data 
stream at twice the baud rate for 100,200, 
and 300 baud. Sampling at twice the baud rate 
will take care of problems caused by sampling 
near the edge of a bit. A program was written 
to do a brute force algorithm using the fastest 
assembly language techniques to check for all 
possible G-TOR frames; the program ended 

up using about 1/3 of the available cycles of a 
50 MHz 486DX. 


G-TOR is a trademark of Kantronics Co., Inc. 
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Appendix 10 


C Program for Golay Encoding and 
Decoding 


#include “stdlib. h” 

#include “stdio. h” 

#include “string. h” 

#include “ctype. h” 

unsigned g[4096],wt[ 4096]; 

unsigned b[ 12]= 
{0xDC5,0xB8B,0x717,0xE2D,0xC5B,0x8B7, 
0x16F,0x2DD,0x5B9,0xB71,0x6E3,0xF FE}; 

ae create_golay_table(void) 


unsigned i ,j ,data; 
for(i=0;i<4096;i1++) 


{ 
i silat 12;j++) 
ifti&(0x800>>j))data*=blj]; 
_——— 
} 


void create-weight-table(void) 


{ 

unsigned i,j ,data; 

for(i=0;i<4096;i++) 
{ 


ead acai j>>=1) 
‘i )data++; 

‘ieciiaii 

} 

main(argc,argv) 

int argc; 

char *argv[); 

{ 


unsigned input,parity,i; 


if(argc<2 I I arge>3 I I isalnum(argv[1)[0])==0) 


displays golay coding of ” 


printf(“g xxx 
“hex value xxx\n”); 


printf(“g xxx yyy displays results of error ” 


“correction of xxx data ” 
“and yyy parity \n”); 
return(Q); 


} 
if(sscanf(argv[1],’%x”,&input)!=1) 


printf(“invalid data input\n”); 
exit(1); 


J 
if(input>OxFFF) 


{ 
printf(“input too large\n”); 
exit(2); 


create_golay_table(); 
create-weight-tableo; 
if(argc==2)printf(“%3.3X ==>” 

“%3.3X\n” input,g[input]); 
else 


if(sscanf(argv[2],"%x” ,&parity)!=1) 
{ 


printf(“invalid parity input\n”), 
exit(3); 


} 
ernest 


printf(“parity too large\n”); 
exit(4); 


en renee 


printf(“%3.3X and %3.3X ==>” 
“%3.3X\n” input,parity,g[parity]); 
return(Q); 


for(i=0;i<12;i++) 
li ai la 


printf(“%3.3X and %3.3X ==>” 
“%3.3X\n”", 
input,parity,g[parity]“bli]); 
return(Q); 


} 
a esata aioe 


printf(“%3.3X and %3.3X ==>” 
“%3.3X\n" input,parity,input); 
return(0); 


} 
for(i=0;i<12;i++) 
if(wt[glinput]“parity“bl[i]]<=2) 


printf(“%3.3X and %3.3X ==>” 
“%3.3X\n”", 
input,parity,input“(0x800>>i)); 
return(Q); 


} 
printf(“cannot correct \n”); 
} 


return(Q); 
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A ndix 11 Ox2A 001010001100 __ ;* Ox5A 1100011001 
Ppe d Ox2B 111100111110 = ;+ 0x5B 00101000110100 ; 


Z 

[ 

Huff man Table 0x2C 1100101 : Ox5C 11110000110101_;\ 
] 

AN 


5. 
= 


0x2D 00010101111 11110000110111_ ‘; 


by ASCII Code ; 

Ox2E 1100100 . Ox5E 11000110111111_ ; 

Ox2F 11110011110 -/ Ox5F 111100001100 = ;_ 
Ox00 1111000011111000 0x30 11000111 -() 0x60 11110000111000 ; 
0x01 1111000011111001 0x31 001010000 “1 0x61 01000 ‘a 
0x02 1111000011111010 0x32 0001011010 2 0x62 0000110 b 
0x03 1111000011111011 0x33 0001011011 3 0x63 010011 C 
0x04 1111000011111100 0x34 0001011100 -4 0x64 00111 “d 
0x05 1111000011111101 0001010101 5 0x65 011 e 
0x06 1111000011111110 0001011101 6 0x66 0000111 f 
0x07 1111000011111111 0001011110 7 0x67 000111 2 
0x08 1111000011110010 0001011111 8 0x68 000100 ch 
0x09 1111000011110011 0001010010 9 0x69 1101 sj 
Ox0A 001101 00101000111 ¥ Ox6A 00010100110 -j 
0x0B 1111000011110100 11110000110100 ; 0x6B 0010101 ‘k 
Ox0C 1111000011110101 0001010111010 Ox6C 000010 | 
Ox0D 001100 1111000010 Ox6D 001011 “m 
OxOE 1111000011110110 111100111111 Ox6E 0101 n 
OxOF 1111000011110111 1100110101 2 Ox6F 010010 0 
0x10 1111001110000000 0001010111000 ;@ 0x70 11000010 D 
Oxl1 1111001110000001 00101001 “A Ox71 1111010110 -q 
0x12 1111001110000010 11001111 -B Ox72 1110 r 
0x13 1111001110000011 11110001 -C 0x73 00100 s 
0x14 1111001110000100 11110100 ‘D 0x74 00000 ot, 
0x15 1111001110000101 11000000 -E Ox75 11111 “u 
0x16 1111001110000110 11001100 -F 0x76 11000011 “y 
0x17 1111001110000111 00010100111 -G 0x77 0001100 W 
0x18 1111001110001000 0010100010 ‘H 0x78 1100011010 “x 
0x19 1111001110001001 0x49 11110010 aI 0x79 0001010110 ‘y 
Ox1A 1111001110001010 Ox4A 1100000110 ‘J Ox7A 1100010 “7, 
Ox1B 1111001110001011 0x4B 1100110100 ‘K Ox7B 11000110111110  ;{ 
Ox1C 1111001110001100 Ox4C 110011101 ‘L Ox7C 11110000110110  ;! 
OxID 1111001110001101 Ox4D 111101010 *M Ox7D 11000110111101  ;} 
Ox1E 1111001110001110 Ox4E 111100000 ‘N Ox7E 11000110111100 ;~ 
OxIF 1111001110001111 Ox4F 000101000 n0) Ox7F 1111000011110001 
0x20 10 7S 0x50 000101100 :P 111100110xxxxxxx ;upper ascii 
Ox21 11110011101 | 0x51 00101000110101 ;Q 0x80 1111001100000000 
0x22 110001101100 _ ;" 0x52 110000010 -R OX81 1111001100000001 
0x23 0010100011011 = ;# 0x53 1111011 ‘SS 0X82 1111001100000010 
0x24 0001010111001 ;$ 0x54 0001101 ‘T etc. 
0x25 110001101101 ;% 0x55 1100000111 U IDLE 1111000011110000 
0x26 111100111001 & 0x56 1100011000 ‘V RLE 11110000111001 
0x27 110001101110 _——s;’ 0x57 0001010100 -W 
0x28 110011011 ( 0x58 0001010111011 ;X UNUSED 1111000011101 
0x29 110011100 2) 0x59 1111010111 -Y 
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Huffman Table 0x52 110000010 -R 0x60 11110000111000 =; 
by Huffman Code 0x32 0001011010 2 Ox7B 11000110111110  ;{ 
0x33 0001011011 3 Ox7C 11110000110110 31 
0x20 10 ee 0x34 0001011100 -d Ox7D 11000110111101 — ;} 
0x65 O11 -@ 0x35 0001010101 5 Ox7E 11000110111100 ;~ 
0x69 1101 4 0x36 0001011101 6 RLE 11110000111001 
Ox6E 0101 1 0x37 0001011110 7 0x00 1111000011111000 
0x72 1110 r 0x38 0001011111 8 Ox01 1111000011111001 
Ox61 01000 ‘a 0x39 0001010010 9 0x02 1111000011111010 
0x64 00111 -d Ox3D 1111000010 vs 0x03 1111000011111011 
0x73 00100 S Ox3F 1100110101 iF 0x04 1111000011111100 
0x74 00000 t 0x48 0010100010 -H 0x05 1111000011111101 
0x75 11111 “u Ox4A 1100000110 “J 0x06 1111000011111110 
Ox0OA 001101 ‘LF 0x4B 1100110100 -K 0x07 1111000011111111 
Ox0OD 001100 -CR 0x55 1100000111 U 0x08 1111000011110010 
0x63 010011 C 0x56 1100011000 ‘V 0x09 1111000011110011 
0x67 000111 9 0x57 0001010100 W OxOB 1111000011110100 
0x68 000100 -h 0x59 1111010111 -Y oxoc 1111000011110101 
Ox6C 000010 “| Ox5A 1100011001 “7, OxOE 1111000011110110 
Ox6D 001011 ‘m 0x71 1111010110 “q OxOF 1111000011110111 
Ox6F 010010 0 0x78 1100011010 “x Ox10 1111001110000000 
Ox2C 1100101 7 0x79 0001010110 ‘y 0xll 1111001110000001 
Ox2E 1100100 . Ox21 11110011101 | 0x12 1111001110000010 
0x53 1111011 °S Ox2D 00010101111 = 0x13  1111001110000011 
0x54 0001101 T Ox2F 11110011110 -/ 0x14 1111001110000100 
0x62 0000110 b Ox3A 00101000111 r 0x15 1111001110000101 
0x66 0000111 f 0x47 00010100111 “G 0x16 1111001110000110 
0x6B 0010101 -k Ox6A 00010100110 -j 0x17 1111001110000111 
0x77 0001100 Ww 0x22 110001101100 _ ;" 0x18 1111001110001000 
Ox7A 1100010 “7, 0x25 110001101101 2% 0x19 1111001110001001 
0x30 11000111 -() 0x26 111100111001 -& Ox1A 1111001110001010 
0x41 00101001 A 0x27 110001101110 : Ox1B 1111001110001011 
0x42 11001111 -B Ox2A 001010001100 7 Ox1C 1111001110001100 
0x43 11110001 Cc Ox2B 111100111110 + Ox1D 1111001110001101 
0x44 11110100 D Ox3E 111100111111 -> OxlE 1111001110001110 
0x45 11000000 -F Ox5F 111100001100 a Ox1F 1111001110001111 
0x46 11001100 FE 0x23 0010100011011 ~—;# Ox7F 1111000011110001 
0x49 11110010 a 0x24 0001010111001 ~ ;$ 111100110xxxxxxxupperascii 
0x70 11000010 D Ox3C 0001010111010 ;« 0x80 1111001100000000 
0x76 11000011 “Vv 0x40 0001010111000 ;@ OX81 1111001100000001 
0x28 110011011 -( 0x58 0001010111011 ;X OX82 1111001100000010 
0x29 110011100 -) UNUSED 1111000011101 etc, 
0x31 001010000 1 Ox3B 11110000110100 ;; IDLE 1111000011110000 
Ox4C 110011101 Li 0x51 00101000110101 ;Q For the Huffman decoding tree, 
Ox4D 111101010 -M 0x5B 00101000110100 ;f see Appendix 9. 
Ox4E 111100000 -N Ox5C 11110000110101 ;\ 
Ox4F 000101000 a0 Ox5D 11110000110111 ;] 
0x50 000101100 “Pp Ox5E 11000110111111 ;” 
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